一、背景
code review本质是鼓励开发者间更多的沟通，互相学习，营造技术文化氛围。
code review按照后面咋们讨论的check清单一项一项的检查, 以此来降低项目
出现的一些低级别的错误和没cover 到场景等错误. 定期总结和优化check 清
单, 熟悉模块之间的依赖, 后期逐步提高开发效率, 丰富全局考虑问题的思
维, 有利于开发之间学习和成长。code review 比较符合从有到优的发展阶段。
code review 的目标长期来看，收益是提升团队的项目质量，减少团队陷入反
复修复 bug 的困境中，让团队有机会去面对更多的挑战。
code review 对个人和团队而言都是成长的机会，要用开放的包容的心态去接
受不同的意见，取其精华。
二、目标
1、每月选一人分享一次，内容包括：过去一个月code review心得与经验总结，
新增并列举些review项，耗时不超过半个小时。
2、Code Review 要计入开发的工作量，建议最好2小时以内，不超过4个小时
3、在提交测试之前做code review
4、一次提交代码行数不宜多，功能完整。
5、大功能代码review需要当面沟通，提高效率
6、每次review完至少做一次赞赏，本身review是离开舒适区的表现。code review
并不只是为了找错，看到好的代码，不要吝啬你的赞美.
7、优先级问题，先专注自己的工作，后code review, 应当在一个工作日之内回应
Code Review请求，Code Review应该越快越好. 务必趁热打铁，因为一个星期后可
能自己写的代码都不认识。
三、check list
0、线程安全问题：使用多线程注意存取值问题。
1、事务：事务操作过程中出错是否能回滚？如果无法实现事务，是否需要做job补偿？
(如：事务没更新完数据库，就异步获取数据库的数据，结果获取的还是旧的数据)。
2、兼容，旧代码变更，是否影响到老接口的逻辑，是否应该做兼容。
3、单元测试，最好能覆盖每个条件流转，方法封装是否合理, 可读性强（如时间格式
转换，组装请求数据等）除非是P1,P2 hotfix上线，一般情况下，都要求提交的代码
有单元测试。
4、注释；复杂难以让人理解的方法要写注释，内容包括业务背景，目的，参数的含义
5、信息同步，排查很多问题不是bug, 而是业务或者测试没有信息同步。写完代码最
好针对单元测试每种情况跟测试、PO沟通一下。如：出现某种异常是否影响到下游继
续执行。个人方法：我理解的讲一遍给对方听，然后让对方复述，然后根据复述提出
一些问题，确保思路保持一致。
6、时区问题，多机房部署可能有时区问题。
7、切分支问题，测试测一半了发现分支没切，耗测试时间，切分支之前在群里喊一声。
8、是否考虑性能，如：for循环调接口，建议改成批量调。需要高性能的接口要打上请
求耗时时间。
9、纯技术：mysql死锁异常，两个事务互相要锁；kafka消费线程挂起，kafka消息堆积；
发消息是否有确认回执；sql注入，mybatis 的$慎用，建议用#。
10、异常处理，特别注意是否可能出现空指针，如果有则需要及时判空。
11、粗心、低级别错误。比如设值问题：在写代码的时候，写的很快，或者有点犯困，
ide工具有自动补全功能，一不小心把setAAB写成setAAA了，导致一些值设置错误。
12、catch块，调第三方或者可能出异常的地方（黑盒）没加catch块，调不通或者向
上抛异常影响代码继续向下执行。
13、添加关键日志，排查问题找不到日志，排查困难。
14、条件覆盖；写代码时一些条件流转的细节场景没有沟通到位，直接忽略导致因为
忽略出现了问题，需考虑到每种else的场景。
15、业务功能细节；需求了解，开发务必读通需求文档，分析到影响的每个地方，
对于复杂流程最好能加以详细文档梳理。
16、魔法值太多，难以调整，静态变量要大写，统一存放.可能多次出现的常量值统
一用ENUM表示。后期如果有需求调整常量值，而这个常量值多个地方出现。调整代码
范围大，对后面维护人员不友好。
17，如果是复杂功能开发，则需补充详细设计文档负责的模块、以及考虑代码执行顺序。
18，预估频繁修改的配置，比如job的执行时间，放到leconf配置中心里。
19、返回值一定要定错误码和错误信息，并同步到上游，提高后期排查问题的效率。
20，对于管理系统，字段是必填项还是可选项。
四、解决方案分析
1、
五、指标评估
1、
六、问题障碍与资源
1、 后期需要公司XX部门的配合，让工具来辅助code review，将需求提给XX
2、具体code review落地执行困难重重，目前没有比较好的指标去评估，全靠自觉。
七、后期改进
1、引入工具来做第一步静态代码自动化扫描
2、不断完善check list
八、Q & A
1）有人认为 Code Review 流程太长，太浪费时间，特别是业务逼，工期紧的时候，今天
改的代码，明天就要上，如果等同事 Review，同事还有可能没时间。
目前阶段不应该认为，因为工期紧导致没有时间 Code Review 的。而且 Code Review 熟
练之后，并不需要花费太长的时间。尽管开始做 Code Review 的时候，你可能因为不熟练，
需要有一个 check list 对照着来 Review，比较耗时，但当你熟练之后，Code Review 就像
键盘盲打一样，你已经忘记了哪个手指按的是哪个键了，扫一遍代码就能揪出绝大部分问题。
2）ROI（投入产出比）不高。
对于很多非功能性的，比如代码的可读性，扩展性，后期维护性，组织结构是否合理，性能问
题等都是无法考察的。比如，代码复杂混乱，可读性查，代码组织结构难以支撑业务扩展，后
期新功能开发还是要补上这些旧债，如梳理，调整结构等等。
九、参考附录
google文档：
https://google.github.io/eng-practices/review/reviewer/standard.html
前人经验: https://tangguangyao.github.io/2015/11/08/%E4%B8%BA%E4%BB%80%E4%B9%88%E8%A6%81%E5%9D%9A%E6%8C%81code%20review/
https://blog.csdn.net/shgh_2004/article/details/78559762
https://blog.fundebug.com/2019/03/28/is-code-review-necessary/
https://www.cnblogs.com/xiao2shiqi/p/13490011.html
维百：https://en.wikipedia.org/wiki/Code_review
StackOverflow：https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/
开源贡献的code review：https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md
十、分享人记录
日期 分享人 分享纪要（url）
额外
思考感悟：思考、总结、抽象、实践、思考
项目感悟：文档化、工具化
